home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / scc / 9005 < prev    next >
Text File  |  1991-07-10  |  10KB  |  215 lines
  1. ***********************************************************************
  2. DDN Security Bulletin 90-05      DCA DDN Defense Communications System
  3. 20 Mar 90                Published by: DDN Security Coordination Center
  4.                                      (SCC@NIC.DDN.MIL)  (800) 235-3155
  5.  
  6.                         DEFENSE  DATA  NETWORK
  7.                           SECURITY  BULLETIN
  8.  
  9. The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
  10. Coordination Center) under  DCA contract as  a means of  communicating
  11. information on network and host security exposures, fixes, &  concerns
  12. to security & management personnel at DDN facilities.  Back issues may
  13. be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73]
  14. using login="anonymous" and password="guest".  The bulletin pathname is
  15. SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin is issued
  16. and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
  17. **********************************************************************
  18.  
  19.  
  20. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  21. !                                                                       !
  22. !     The following important  advisory was  issued by the Computer     !
  23. !     Emergency Response Team (CERT)  and is being relayed unedited     !
  24. !     via the Defense Communications Agency's Security Coordination     !
  25. !     Center  distribution  system  as a  means  of  providing  DDN     !
  26. !     subscribers with useful security information.                     !
  27. !                                                                       !
  28. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  29.  
  30.  
  31.                 CERT Advisory
  32.                 March 19, 1990
  33.               Internet Intruder Warning
  34.  
  35. There have been a number of media reports stemming from a March 19 New
  36. York Times article entitled 'Computer System Intruder Plucks Passwords
  37. and Avoids Detection.'  The article referred to a program that
  38. attempts to get into computers around the Internet.
  39.  
  40. At this point, the Computer Emergency Response Team Coordination
  41. Center (CERT/CC) does not have hard evidence that there is such a
  42. program.  What we have seen are several persistent attempts on systems
  43. using known security vulnerabilities.  All of these vulnerabilities
  44. have been previously reported.  Some national news agencies have
  45. referred to a 'virus' on the Internet; the information we have now
  46. indicates that this is NOT true.  What we have seen and can confirm is
  47. an intruder making persistent attempts to get into Internet systems.
  48.  
  49. It is possible that a program may be discovered.  However, all the
  50. techniques used in these attempts have also been used, in the past, by
  51. intruders probing systems manually.
  52.  
  53. As of the morning of March 19, we know of several systems that have
  54. been broken into and several dozen more attempts made on Thursday and
  55. Friday, March 15 and 16.
  56.  
  57. Systems administrators should be aware that many systems around the
  58. Internet may have these vulnerabilities, and intruders know how to
  59. exploit them.  To avoid security breaches in the future, we recommend
  60. that all system administrators check for the kinds of problems noted
  61. in this message.
  62.  
  63. The rest of this advisory describes problems with system
  64. configurations that we have seen intruders using.  In particular, the
  65. intruders attempted to exploit problems in Berkeley BSD derived UNIX
  66. systems and have attacked DEC VMS systems.  In the advisory below,
  67. points 1 through 12 deal with Unix, points 13 and 14 deal with the VMS
  68. attacks.
  69.  
  70. If you have questions about a particular problem, please get
  71. in touch with your vendor.
  72.  
  73. The CERT makes copies of past advisories available via anonymous FTP
  74. (see the end of this message).  Administrators may wish to review
  75. these as well.
  76.  
  77. We've had reports of intruders attempting to exploit the following
  78. areas:
  79.  
  80.  
  81. 1) Use TFTP (Trivial File Transfer Protocol) to steal password files.  
  82.  
  83.    To test your system for this vulnerability, connect to your system
  84. using TFTP and try 'get /etc/motd'.  If you can do this, anyone else
  85. can get your password file as well.  To avoid this problem, disable
  86. tftpd.
  87.  
  88.    In conjunction with this, encourage your users to choose passwords
  89. that are difficult to guess (e.g. words that are not contained in any
  90. dictionary of words of any language; no proper nouns, including names
  91. of "famous" real or imaginary characters; no acronyms that are common
  92. to computer professionals; no simple variations of first or last
  93. names, etc.)  Furthermore, inform your users not to leave any clear
  94. text username/password information in files on any system.
  95.  
  96.    If an intruder can get a password file, he/she will usually take it
  97. to another machine and run password guessing programs on it. These
  98. programs involve large dictionary searches and run quickly even on slow
  99. machines.  The experience of many sites is that most systems that do
  100. not put any controls on the types of passwords used probably have at
  101. least one password that can be guessed.
  102.  
  103.  
  104. 2) Exploit accounts without passwords or known passwords (accounts
  105. with vendor supplied default passwords are favorites).  Also uses
  106. finger to get account names and then tries simple passwords.  
  107.  
  108.    Scan your password file for extra UID 0 accounts, accounts with no
  109. password, or new entries in the password file.  Always change vendor
  110. supplied default passwords when you install new system software.
  111.  
  112.  
  113. 3) Exploit holes in sendmail.
  114.  
  115.    Make sure you are running the latest sendmail from your vendor.
  116. BSD 5.61 fixes all known holes that the intruder is using.  
  117.  
  118.  
  119. 4) Exploit bugs in old versions of FTP; exploit mis-configured
  120.    anonymous FTP
  121.  
  122.    Make sure you are running the most recent version of FTP which is
  123. the Berkeley version 4.163 of Nov.  8 1988.  Check with your vendor
  124. for information on configuration upgrades.  Also check
  125. your anonymous FTP configuration.  It is important to follow the
  126. instructions provided with the operating system to properly configure
  127. the files available through anonymous ftp (e.g., file permissions,
  128. ownership, group, etc.).  Note especially that you should not use your
  129. system's standard password file as the password file for FTP.
  130.  
  131.  
  132. 5) Exploit the fingerd hole used by the Morris Internet worm.
  133.  
  134.    Make sure you're running a recent version of finger.  Numerous
  135. Berkeley BSD derived versions of UNIX were vulnerable.
  136.  
  137.  
  138. Some other things to check for:
  139.  
  140. 6) Check user's .rhosts files and the /etc/hosts.equiv files for systems
  141. outside your domain.  Make sure all hosts in these files are
  142. authorized and that the files are not world-writable.
  143.  
  144.  
  145. 7) Examine all the files that are run by cron and at.  We've seen
  146. intruders leave back doors in files run from cron or submitted to at.
  147. These techniques can let the intruder back on the system even after
  148. you've kicked him/her off.  Also, verify that all files/programs
  149. referenced (directly or indirectly) by the cron and at jobs, and the
  150. job files themselves, are not world-writable.
  151.  
  152.  
  153. 8) If your machine supports uucp, check the L.cmds file to see if
  154. they've added extra commands and that it is owned by root (not by uucp!)
  155. and world-readable.  Also, the L.sys file should not be world-readable
  156. or world-writable.
  157.  
  158.  
  159. 9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
  160. entries.  Some alias files include an alias named 'uudecode'; if this
  161. alias exists on your system, and you are not explicitly using it, then
  162. it should be removed.
  163.  
  164.  
  165. 10) Look for hidden files (files that start with a period and are
  166. normally not shown by ls) with odd names and/or setuid capabilities,
  167. as these can be used to "hide" information or privileged (setuid root)
  168. programs, including /bin/sh.  Names such as '..  ' (dot dot space
  169. space), '...', and .xx have been used, as have ordinary looking names
  170. such as '.mail'.  Places to look include especially /tmp, /usr/tmp,
  171. and hidden directories (frequently within users' home directories).
  172.  
  173.  
  174. 11) Check the integrity of critical system programs such as su, login,
  175. and telnet.  Use a known, good copy of the program, such as the
  176. original distribution media and compare it with the program you are
  177. running.
  178.  
  179.  
  180. 12) Older versions of systems often have security vulnerabilities that
  181. are well known to intruders.  One of the best defenses against
  182. problems is to upgrade to the latest version of your vendor's system.
  183.  
  184.  
  185. VMS SYSTEM ATTACKS:
  186.  
  187. 13) The intruder exploits system default passwords that have not been
  188. changed since installation.  Make sure to change all default passwords
  189. when the software is installed.  The intruder also guesses simple user
  190. passwords.  See point 1 above for suggestions on choosing good
  191. passwords.
  192.  
  193. 14) If the intruder gets into a system, often the programs
  194. loginout.exe and show.exe are modified.  Check these programs against
  195. the files found in your distribution media.
  196.  
  197.  
  198. Past advisories and other information are available for anonymous ftp
  199. From cert.sei.cmu.edu (128.237.253.5).
  200.  
  201. ------------------------------------------------------------------------------
  202.  
  203. If you believe that your system has been compromised, contact the
  204. Defense Communications Agency DDN/MILNET Monitoring Center and CERT
  205. via telephone or email.
  206.  
  207. MILNET Monitoring Center
  208. Telephone: 800-451-7413 or 202-692-5726 (commercial)
  209.            312-746-1849 (DSN)
  210.  
  211.  
  212. CERT
  213. Internet: cert@cert.sei.cmu.edu
  214. Telephone: 412-268-7090 24-hour hotline
  215.